Cross-boundary Security Analysis

The goal of the project was to develop new methods to discover security vulnerabilities and security exploits. The research involved static analysis, dynamic analysis, and symbolic execution of software at both the source-code and machine-code levels. An aspect that distinguished the approach taken in the project from previous work was the attempt to uncover security problems due to differences in outlook between different levels of a system—an approach called cross-boundary security analysis. The term refers both to (i) translation effects where the source-level outlook and the machine-code-level outlook differ, as well as (ii) differences in outlook between a source-level view of a component’s API and the machine code that implements the component, which can sometimes allow a sequence of API calls to drive a program to a bad state. In both cases, one has two different artifacts that are supposed to have the same semantics, but whose semantics actually differ. 1 Objective and Technical Approach Recent research in the fields of programming languages, software engineering, and program verification has led to new kinds of tools for analyzing programs for bugs and security vulnerabilities. In these tools, program analysis conservatively answers the question “Can the program reach a bad state?” Many impressive results have been achieved; however, the vast majority of existing tools analyze source code, whereas most programs are delivered as machine code. If analysts wish to vet such programs for bugs and security vulnerabilities, tools for analyzing machine code are needed. The project “Cross-Boundary Security Analysis” focused on the analysis of machine code. The objective of the project was both to find security vulnerabilities (i.e., flaws in software), as well as inputs to the programs that capitalize on these flaws (exploits). The plan was also to do this for multiple hardware platforms (i.e., for multiple instruction sets). The original insight behind the research undertaken in the project was that there are often differences in outlook when one examines different levels of a system. “Different levels” applies to several aspects of software: across module boundaries (e.g., a client application and the libraries that is uses), as well as across the source-code/machine-code translation boundary. However, the notion of “differences in outlook” was not well understood—and hence